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Description 
Procede et dispositif pour l'interfagage graphique 

[001] La presente invention concerne un proc6d6 ainsi qu'un dispositif pour l'interfa£age 
graphique entre un utilisateur et un systeme informatique. 

[002] Elle trouvera en particulier son application dans le domaine de la realisation 

d' interface graphique pour utilisateur, notamment dans le domaine des systemes de re- 
servation par ordinateur. 

[003] D'une fafon g£n6rale, les interfaces utilisateurs ont connu une grande Evolution 

depuis Vimportant succes des r6seaux de large extension et en particulier de l'lnternet. 

[004] Les solutions d'interfagage graphique dans le cadre d'Internet ont permis 
d'importantes economies en matiere de d6veloppement 

[005] Cependant, pour des applications complexes, telles que des applications profes- 

sionnelles de systemes de reservation par ordinateur, les interfaces d'utilisateurs bashes 
sur ces techniques nScessitent le transfert de graindes pages volumineuses dans un 
format de balisage du type HTML (pour Hyper Text Mark-up Language). 

[006] Des inconv6nients li& k ce type de transmission de pages integrates form6es 

uniquement dans la partie serveur et txansmises an navigateur du poste client posent 
plusieuts problemes. En particulier, la partie client de 1' interface d' utilisation present© 
d'importantes limitations structurelles, liees au langage HTML. En outre, compte-tenu 
du volume des transferts k op&er entre le serveur et le poste client, Inoccupation du 
r6seau de transmission est forte, ce qui implique un temps de r6ponse 61ev6 pour les 
clients disposants d'une connexion a faible debit. 

[007] Ce type de construction de pages HTML ressort du document US-A-20021 16455. 

[008] Suivant des techniques un peu diff&entes, des feuilles de style (stylesheets) sont 
stock6es localement pour etre r£utilisees, en fusion avec des dossiers dynarniques. 
Cependant, ces feuilles de style sont pi6d6finies et leurs caract&istiques sont fixees d6- 
finitivement Elles n'offrent aucune souplesse d' utilisation. Par exemple, s'il convient 
de cr6er une page avec une feuille de style diffSrant, meme de fagon minime, de la 
feuille presente dans le cache local, la feuille locale n'est pas exploitable et il faut 
obtenir une nouvelle feuille de style complete depuis le serveur. 

[009] II existe un besoin concernant des interfaces utilisateur disposant des atouts de 

richesse, de flexibilit6 et de performance des traitements op6r6s dans la partie serveur 
tout en assurant une reduction de Toccupation du reseau pour fournir l'affichage au 
client 

[010] La pr€sente invention s'inscrit dans le cadre de cette optimisation et permet de 

r£duire d'une part le temps de calcul sur le serveur et d' autre part le trafic sur le r6seau 
entre le serveur et le client, ce qui permet de diminuer le temps de rgponse global de 
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F application. En outre, le dispositif de 1' invention conserve une grande flexibilite car 
la partie serveur continue de contr81er le traitement des donnees & afficher. Le 
dispositif permet 6galement de modifier et de cr^er les modules de visualisation 
graphique a afBcher pour l'utilisateur ainsi que de fournir des instructions en ce qui 
concerne Faffichage au poste client. 

[01 1] Plus prgcis6ment, Finvention a Favantage de fournir aux moyens de visualisation 
des informations fusionnees entre deux sources de donnees. En effet, d'une part, le 
dispositif de Finvention g6n£re des objets statiques conserves localement au niveau du 
poste client et peimettant une disponibilitS locale de multiples objets graphiques 
utilises pour Faffichage. 

[012] D' autre part, les donnfes dynamiques correspondant k la demande du client sont 
gdngnSes apr&s traitement dans la partie serveur et transmises au poste client. Une 
fusion des donnees dynamiques et statiques est ensuite op6x6e pour produire la vi- 
sualisation en particulier sous forme de pages au format HTML en utilisant une ap- 
plication de navigation. 

[013] En implementant un equipement sp6cifique au niveau du poste client, on peut 
g6n6rer localement le module de visualisation h exploiter pour Faffichage. Cela est 
op6x6 par F association de difffcrents Pigments de constructions du module qui seront 
d6taill6s plus loin dans la description. 

[014] II s'ensuit que les donnfes de construction des modeles de visualisation ne 

transitent plus par le r6seau. En outre, le sysfeme est aisement personnalisable selon les 
exigences locales du poste client (objets graphiques sp&ifiques, regies logiques par- 
ticulieres h appliquer, donnees locales particuli&res h employer. . 

[015] Cette personnalisation potentielle du poste client n'affecte pas ses constituants 

d'origine et en particulier le navigateur : on peut en effet g6n6rer une page au format 
HTML directement exploitable par le navigateur. 

[016J On notera 6galement que, les modules de visualisation 6tant crd6s a partir d'objets 
de faibles tailles, leur mise & jour ne n6cessite que peu de ressources r6seau. 

[0 17] On reduit ainsi consid6rablement le volume des donates h traasmettre entre la 
partie serveur et le poste client C'est ainsi que Fon ben6ficie de la richesse des 
standards de langage de balisage (tel HTML) tout en diminuant consid&ablement le 
temps de rdponse et les besoins en i£seau. 

[018] D'autres buts et avantages apparaitront au cours de la description qui suit d'un 
mode pr6f6r6 de realisation de Finvention qui n'est cependant pas limitatif. 

[019] La pr&ente invention concerne un proc6d6 pour Finterface graphique entre un 
utilisateur et un systeme infonnatique dans lequel on effectue les actions suivantes : 

- entree d'une demande par Futilisateur au niveau d'un poste client, 

- Transmission de la demande vers une partie serveur en vue du traitement de la 
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demande et de la g6n6ration d'une r6ponse, 

- Reception de la rgponse au niveau du poste client, 
Affichage du r&ultat de la rgponse pour V utilisateur, 

[020] Selon l'invention : 

- Le poste client regoit une r£ponse comprenant des donnfes d' instruction et 
des donnees a afficher ; 

- Au niveau du poste client, on execute les donn6es d'instruction pour la 
construction d'un module de visualisation h exploiter ; 

- Au niveau du poste client, on cr6e ledit modele de visualisation par as- 
sociation d' elements de construction disponibles localement, 

- On fusionne les donnfies h. afficher avec le modfele de visualisation en vue de 
F affichage du rdsultat de la fusion. 

[021] Suivant des possibility avantageuses mais non limitatives : 

- Les Elements de construction comprennent une interface de description des 
objets du modele de visualisation, une couche de presentation et des regies 
logiques a appliquer localement au module de visualisation ; 

- Au niveau du poste client, on associe au modele de visualisation cr6e un 
ressource de langage parmi les ressources de langage disponibles localement ; 

- Au niveau du poste client, on peut associer au module de visualisation des 
filtres de personnalisation d' affichage pour modifier le rendu visuel du 
module de visualisation par ddfaut; 

Les donnees d'instruction component l'indication du type et les 616ments ca- 
ract&istiques de construction de module de visualisation a cr6er ; 

- On met & jour les donnees disponibles localement au niveau du poste client 
par les 6tapes suivantes : 

• On g^nfere, au niveau du serveur, un message de stockage comprenant des 
donn6es d'instruction de stockage et les donn£es h stacker, 

• On transmet le message de stockage au poste client, 

• Au niveau du poste client, on interpr&te les donnees d'instruction pour 
ex^cuter le stockage et on stocke les donnees k stocker dans une m&noire 
locale. 

- On effectue 1' affichage au niveau du poste client par une application de 
navigation, 

- On utilise des donnges h afficher et des 616ments de construction des modules 
de visualisation au format XML 

On traduit le rgsultat de la fusion au format HTML en vue de l'affichage. 

- La r6ponse de la partie serveur comprend des donn£es d'instruction et des 
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donnees k afficher ; 

[022] L'invention est aussi relative k un dispositif d'interfagage graphique entre un 
utilisateur et un systeme inf ormatique comprenant : 

• Des moyens d' entree d'une demande par l'utilisateur au niveau d'un poste 
client, 

• Des moyens de communication entre le poste client et une partie serveur, 

• Des moyens de traitement dans la partie serveur pour la generation d'une 
reponse, 

• Des moyens d'affichage du r6sultat de la r6ponse au niveau du poste client 

- II comporte au niveau du poste client un gestionnaire destructions apte k in- 
terpreter les donn£es d' instruction pour la construction d'un mod&le de vi- 
sualisation k exploiter ; 

II comporte un moteur d'association au niveau du poste client apte k creer 
ledit modfele de visualisation par association d' elements de construction ; 

- H comporte des moyens de stockage des Elements de constructions au niveau 
du poste client ; 

- II comporte au niveau du poste client des moyens pour fusionner le module de 
visualisation et les donnees k afficher, en vue de Faffichage du resultat de la 
fusion. 

[023] Atitrepr6f6r6: 

- Les elements de construction compreiment une interface de description des 
objets du moddle de visualisation une couche de presentation et des rfegles 
logiques k appliquer localement au module de visualisation ; 

- II comporte un moteur de regies apte a appliquer les regies logiques du 
module de visualisation ; 

- E comporte une application de navigation pour V affichage du r6sultat de la 
fusion au niveau du poste client. 

[024] Les dessins ci-joints sont donnas k titre d'exemples et ne sont pas limitatdfs de 
T invention. Us repr6sentent seulement un mode de realisation de rinvention et 
permettront de la comprendre ais£ment. 

[025] La figure 1 est une representation sch6matique du traitement op6i6 actuellement 
entre un client et un serveur lorsqu'une requete est formuiee par un client en utilisant 
une architecture basee sur le systeme Internet et 1' usage d'un navigateur du type 
Internet Explorer ®. 

[026] La figure 2 presente schematiquement le traitement d'une demande par un client 

avec mise en ceuvre de P invention. 
[027] La figure 3 illustre des blocs d' elements constitutifs du dispositif de rinvention et 

leur communication. 
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[028] La figure 4 montre '6tape de fusion de donn6es r6alis6es. 

[029] La figure 5 est un exemple de composant int6gr6 dans les moyens de visualisation 
du poste client. 

[030] On a represents en figure 1 un scenario standard lors de Putilisation du reseau 

d' extension mondial usuellement d6nomm6 « World Wide Web ». Dans ce cadre, les 
requites de 1'utilisateur au niveau de la partie client correspondent k une demande de 
page au format HTML (Hyper Text Mark-up Language) avec les instructions 
suivantes ; http get ou http post 

[031] Une premifere limitation de ce m6canisme est que Tutilisateur doit prgciser la 

fenetre qui va r6aliser V affichage de la r6ponse et ce avant d'envoyer la requete. Le 
serveur ne peut done pas d6cider d'afficher la r6ponse dans une fenetre de dialogue ou 
sur la fenStre principale puisque cela a d6}k 6t6 ddfini au niveau du client 

[032] Un autre inconvenient que Ton peut soulever est qu'une seule fenetre peut etre 

rafraichie k la fois. Par exemple, si la fenetre principale avait 6te divis6e en deux sous- 
fenStres, il est n6cessaire k 1'utilisateur d' adresser deux requetes successives au serveur 
pour obtenir le rafraichissement successif des deux sous fenStres. Par ailleurs, les mo- 
difications d'affichage se font uniquement par rafraichissement de r integrality d'une 
partie de l'gcran alors qu'il est possible que la demande du client ne reponde qu J k une 
simple demande de mise k jour de certaines dotutees. Suivant le dispositif actuel, il est 
cependant n6cessaire de rafraichir F integrality de F6cran pour n'importe quel type de 
modification demandee. 

[033] II n'y a pas de moyen efBcace pour stocker des informations au niveau du poste 
client si ce n'est le recours k des « cookies » (temoins) qui sont cependant de petite 
taille et qui n6cessite un transit par le r6seau k chaque requete. 

[034] Une fois que 1'utilisateur a saisi sa requgte celle-ci est transmise par le biais du 
r6seau Internet avec le support de protocoles de communication du type http (Hyper 
Text Transfer Protocol). Cette 6tape est representee au rep&re 1 a la figure 1. Le 
traitement de la requete est op6r6 au niveau du serveur et est pr6sente au rep&re 2. Une 
r£ponse est ensuite g£n6r6e comme presentee au repfere 3, ici sous forme de page au 
format html qui implique la combinaison dans une meme reponse des elements de 
domtees et des 616ments de presentation de ce qui doit etre affich6 k 1'utilisateur. A 
chaque fois que Ton souhaite acedder k une page, il faut ainsi tetecharger depuis la 
partie serveur l'integralite de la page HTML contenant les donnees k afficher (donnees 
variables et donn6es « statiques » de formatage - ex : textes d'aide, couleurs, polices 
de caractferes.. .). Ainsi le volume des pages transmises sur le r£seau s'avfere important. 

[035] Le repere 4 de la figure 1 montre que la reponse sous forme de page Web est 

adressde au client n faut noter que pour des applications professionnelles les donnees 
doivent etre encryptees ce qui implique un temps de traitement et un cofit induit 
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d'autant plus important que le volume des donn6es a crypter est 61ev6. 
[036] Au niveau du poste client, Futilisateur peut ensuite disposer de Faffichage de la 
r6ponse comme pr6sent6 au point 5 en figure 1 . Cet affichage est r6alis6 par le biais 
d'une application de navigation telle que celle disponible sous la marque Internet 
Explorer ®. 

[037] Au niveau local, certaines actions peuvent alors avoir lieu pour 6viter de recourir 

syst6matiquement au serveur. Ainsi certaines applications par exemple editfies en Java 
Script peuvent etre implementees au niveau du poste client pour produire certains 
outils. Un autre inconvenient des dispositifs actuels est done qu'il n6cessite de recourir 
k des outils additionnels k programmer au langage Java Script au niveau du poste 
client 

[038] La figure 2 presents au contraire un exemple de scenario de fonctionnement d'un 
dispositif d'interfagage graphique selon l'invention. 

[039] Comme indiqu6 pr6cedemment, V architecture actuelle utilis6e dans le cadre du 

reseau Internet (World Wide Web) pose des probfemes dans la mesure oh Fint6gralit6 
de pages au format HTML sont t616charg6es vers le poste client 

[040] Comme visible en figure 2, tel n'est pas le cas de la pr&ente invention. 

[041] Plus particuliferement, lorsque 1'utilisateur entre une requdte k destination de la 
partie serveur, une demande sous forme d'un message contenant les informations 
saisies par Futilisateur est g<Sn6r& au format XML (Extensible Mark-up Language) ou 
sous un autre format structure Dans la mesure oh la demande du client ainsi gen6r6e 
reflate Faction de Futilisateur, elle a 6t6 dSnommee « 6v6nement » k la reference 1 de 
la figure 2. 

[042] Apr&s transmission, cette demande « 6v6nement » est rejue et trait6e au niveau de 
la partie serveur. La premiere phase du traitement consiste en une analyse du contenu 
de la demande ce qui est fait au niveau d'une couche d' interface utilisateur du serveur 
qui sera presents plus en detail ci-apr&s. Ensuite, on procfcde au traitement des donnees 
de la demande « 6v6nement » au niveau d'une couche d'application qui sera egalement 
pr6sent£e plus loin. 

[043] Ces phases sont presentees au repere 2 « traitement » de la figure 2. Une fois que la 
demande a 6t& tnritSe, la partie serveur g6nfcre la r6ponse approprtee k Fattention du 
client Dans ce cadre, au lieu de construire une page au format HTML complete, on 
genere selon Finvention une suite destructions qui sera k interpreter par le client 
Cela donne en particulier une grande flexibility en ce qui concerne le comportement du 
poste client Par exemple, un seul message peut permettre d'op&er des operations de 
rafraichissement d'une partie de Fecran, d'ouvrir une boite de dialogue, d'afficher une 
boite de message etc. . . et ce de fagon simultanee. 

[044] Une fois crde, le message est transmis sous foime d'un document XML (Extensible 
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Mark-up Language) eventuellement apres compression et ciyptage en direction du 
poste client. Cette operation est representee an repene 4 par le terme instruction qui 
correspond k la fonctionnalit£ d6crite au paragraphe pr6c£dent 

[045] Ce message d'instruction est re£U au niveau du poste client et doit etre interprets. 

[046] En particulier, les donnees dynamiques comprises dans la reponse du serveur sont 
r6cup6rees et pourront etre fusionn&s avec un modfele de visualisation qui correspond 
aux objets statiques nScessaires a l'affichage. Chaque modele de visualisation est par 
ailleurs ci66, au niveau du poste client, par association d' Pigments de construction. Ce 
sont les donates d'instruction qui determinent les etements de construction a associer. 
La combinaison par fusion des deux types de donnees (couche de presentation et 
donnees dynamiques issues du serveur) pennet la creation de donn6es completes k 
afficher, en particulier sous forme d'une page au format HTML. On peut dans ce cadre 
utiliser pour la visualisation les fonctionnalites de moyens de navigation connus et 
standard, tels que le navigateur diffus6 sous la marque Internet Explorer ®. 

[047] Les avantages de Vopgration de fusion ainsi r&disde dans la partie client sont 

multiples. En premier lieu, une fois que les modules de visualisation et leurs etements 
de ddpendance (images, scripts, etc... auxquels font appel les modules) ont 6t6 
r6cup6r& et sont disponibles au niveau du poste client, seules les donnees dynamiques 
sont k adresser par le biais du r6seau de communication. On abaisse done f ortement la 
consommation du r£seau. 

[048] La mise k jour des donn6es statiques est de plus trfes 6conome en ressources de 
transmission car il s'agit d'616ments de petite dimension. Par exemple, si un objet 
graphique est k changer, il n'est pas n&essaire de charger tout le module de vi- 
sualisation qui Tutilise. 

[049] En outre, seul le canal de transmission des donnfies a besoin d'etre s6curis6 dans les 
moyens de communication ce qui pennet de limiter les capacity d'encryptage n6- 
cessaires lorsque Ton souhaite securiser les communications. 

[050] Une fois que la fusion est op£r6e, son r£sultat peut etre affichg au niveau du poste 
client tel que pr6sent6 k l'6tape 5 de la figure 2. 

[051] Une interaction locale avec Putilisateur est ensuite possible tel que pr6sente au 
point 6 et met en oeuvre un moteur de regies apte k appliquer des regies logiques 
assoctees au modfele de visualisation exploit^ et disponible localement, tel que cela 
sera precis6 plus loin. EUe peut incline differents fonctionnements. 

[052] En particulier, si les instructions transmises par le serveur correspondent k des 
contrdles (tels un bouton pour raffichage d'une liste dfrouiante), les 6v6nements k 
realiser peuvent etre g6res par un code au format de langage Java Script associ6 au 
controle considdr6. 

[053] Si les 6v6nements k op6rer comportent des interactions entre diffgrents controles 
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(par exemple si le champ A est renseign6, le champ B devient alors obligatoire) on 
peut op6rer de diffSrentes famous. 
[054] Ainsi, si l'interaction est complexe mais rarement utilisfe, elle peut etre g6ree au 
niveau du serveur et demandee sous forme d'une requete formulee par le poste client 
au poste serveur. 

[055] Si l'interaction est simple et peut gtre facilement implementee, elle est g6r6e au 
niveau du poste client par le moteur de regie local. 

[056] Enfin, si aucune des 6ventualit6s pr£c6dentes ne semble opportune, il est possible 
de r6aliser des courts elements de codage au format Java Script a lier k la page pour 
realiser une fonctionnalit6 telle qu'actuellement connue dans le domaine des pages 
HTML utilisees pour le World Wide Web. 

[057] On d<Scrit ci-aprfcs plus prgcisdment une structure possible du dispositif de 

l'invention. Ce dispositif comprend une partie serveur implements avec des moyens 
informatiques connus comprenant des moyens de traitement sous forme de processeur 
et des moyens de stockage sous forme de m&noire du type RAM (Random Access 
Memory) ou ROM (Read Only Memory). La partie serveur s'entend d'une seule entite 
de serveur informatique distant ou de plusieurs serveurs connectes entre eux par des 
moyens de transmission usuels. 

[058] Le dispositif comprend 6galement une partie impl&nentfe localement au niveau du 
poste client pouvant par exemple etre r6alis6e par un ordinateur personnel du type PC 
(Personal Computer), visible en figure 3. 

[059] La partie serveur et le poste client sont relics pour la transmission de donnees par le 
biais de moyens de communication pouvant par exemple etre realises par 
l'intermgdiaire d'un r6seau (R) de large extension (WAN : Wide Area Network). 

[060] On a represents en figure 3 diffcrents constituants du dispositif de l'invention et 
leur relation afin de mettte en oeuvre le proc6d6 d'interfacage ici d&xit. 

[061] Par l'interm&liaire du r6seau represents R, la partie serveur transmet une reponse a 
la demande formulae antSrieurement par Futilisateur, la igponse comprenant des 
donnees destructions et des donnees k afficher. 

[062] On pourra notamment utiliser le standard XML comme format de langage de 

balisage. La rgponse est re$ue au niveau d'un gestionnaire destructions apte k in- 
terpreter les donnees d'instruction contenues dans la reponse pour d&enniner les 
actions a mener. Dans le cas d'un affichage a realiser, Tinterpretation comprend la de- 
termination des 616ments de construction k utiliser pour la gyration du module de vi- 
sualisation. 

[063] Les r6sultats de ^interpretation sont transmis a un moteur d'association apte a 
r&mp&rer les donndes statiques constituant les 6I6ments de construction caract&- 
ristiques du module de visualisation prgcedemment determine. On a represents en 
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figure 3 dif¥6rents 616ments de construction utilis6s pour la creation du modele de vi- 
sualisation. En particulier, Ie module de visualisation associe une interface de 
description dScrivant les composants de haut niveau du modele de visualisation, une 
couche de presentation rassemblant les differents 616ments et attributs lies k une pre- 
sentation graphique et des regies logiques qui correspondent k la logique locale qui 
doit etre appliqu6e au module de visualisation durant son traitement 
[064] A tttre pref6r6, la couche de presentation peut dependre des profils d'utilisateur, 
mais Tinteiface de description et les regies logiques demeurent identiques. Les 
616ments de construction peuvent par consequent etre des donn6es totalement inde- 
pendantes et etre stock6s dans des fichiers separ^s ou dans un meme fichier selon les 
besoins. 

[065] D'autres elements sont par ailleurs avantageusement associ6s aux modules de vi- 
sualisation ainsi crees. En particulier, des donnees de ressources de langage sont 
associ6es. Ces donnees sont 6galement choisies parmi diff6rentes ressources 
disponibles localement en m6moire cache au niveau du poste client. On peut ainsi 
facilement adapter la page k cr6er a une langue predetermine. L'indication de la 
ressource de langage k utiliser est dgalement pr6sente dans les donn6es d'instructions 
revues dans la r£ponse. 

[066] On peut aussi associer au modele de visualisation un ou plusieurs filtres. Ces filtres 
competent la personnalisation rendue possible par la pr&ente invention. En effet, ils 
permettent d'adapter rinformation disponible k F6cran k des parametres particuliers au 
client C'est un moyen particuliferement efficace de modifier les composants visuels de 
l'ficran de fagon non programmatique, par exemple en ce qui concerae les contrdles 
utilisateur (ex : suppression de certains controles de 1' Scran, modification du caractfcre 
obligatoire de certains champs de saisie...) 

[067] Au final, F association du module de visualisation, du ou des filtres, des ressources 
de langage et des donn6es dynamiques re9ues dans la reponse du serveur permet de 
former une page. 

[068] Cette association est pr6sent6e plus particuliferement k la figure 5. 

[069] En revenant k la figure 3, on a repr6sente que la fusion entre les donnees statiques 
ainsi assoctees et les donnees dynamiques contenues dans la reponse s'op&re au niveau 
d'un moyen de fusion. Par le biais de la fusion on peut par exemple, crger des donndes 
au format XML. 

[070] Les applications de navigation standards, en particulier Internet Explorer ®, 
exploitent des pages au format HTML. On effectue done avant la transmission k 
V application de navigation une transformation vers ce format HTML par le biais de 
moyens de transformation. 

[07 1] Les Stapes dSbouchant k la visualisation pour l'utilisateur sont alors celles im- 
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pl6ment6es conventionnellement avec les navigateurs existants. Cependant, pour 
permettre une interaction am<51ior6e avec I'utilisateur sans un recours syst&natique k 
V activite de la partie serveur, le dispositif de l'invention comporte 6galement un 
moteur de regies apte k exploiter les r&gles contenues dans un magasin de donnees. De 
cette fa^on, on peut g6rer des interactions simples entre le navigateur et I'utilisateur. 
Par exemple, on peut determiner localement les donnees k pr6voir dans un menu 
deroulant suivant le profil du client et suivant la saisie precedemment oper6e par 
I'utilisateur. On 6vite ainsi un recours syst&natique k une interrogation du serveur 
apres une saisie du client 

[072] On a 6galement represents en figure 3 une possibilit6 de mise k jour ou d'ajout de 
donnees dans le magasin de donnSes. En effet, il peut etre utile de rafraichir ou 
d'augmenter les donndes contenues localement dans le magasin de donnees et servant 
au moteur de regies. Pour ce faire, on adresse depuis la partie serveur jusqu'au poste 
client une r6ponse contenant des donnees distractions et des donnfes a exploiter, ici 
en vue de leur stockage et non en vue de I'affichage. 

[073] A reception, Instruction de stockage est interpr6t6e ce qui resulte en une action de 
stockage des donnfes contenues dans la r6ponse dans le magasin de donnSes. Cette 
6tape est 6galement representee en figure 3. 

[074] Par ailleurs, le poste client comporte avantageusement un Element de cache 

constituant un moyen de stockage de donn£es disponible au niveau local et dans lequel 
peut etre stockee une plurality de donnees comprenant les diffgrents 616ments de 
construction, n s'agit done de donnees statiques qui sont ggn&alement utilises pour 
des pages de type HTML. Tout type de m&noire peut etre utilise pour une telle 
m&noire cache et en particulier une m&noire morte de type ROM (Read Only 
Memory). 

[075] Suivant une premiere possibility les donn&s statiques sont installs dfes le d6part au 

niveau du poste client et utilises lorsqu'ils sont demandes pour etre fiisionnSs avec des 

donnSes issues du serveur. Ainsi, le serveur n'a pas k transmettre les differents 

616ments ou objets utilises pour I'affichage. 
[076] n peut 6galement arriver que des elements n6cessaires k I'affichage mais non 

presents initialement au niveau du poste client doivent etre utilises. 
[077] Dans ce cadre, la presents invention permet la creation des Stements de construction 

au niveau de la partie serveur et leur transmission une seule fois au poste client pour 

stockage dans le cache et rSutilisation ultSrieure. 
[078] On a repr<5sent6 en figure 4 l'&ape de fusion op6r6e entre les donnees issues du 

serveur et les donnees issues du cache local apres leur association. 
[079] Dans ce cadre, il est represents que la fusion s'effectue dans la partie du poste client 

aprfes reception des donnees dynamiques issues du serveur dans les instructions 
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constitutives de la r6ponse du serveur. Le gestionnaire d' instructions, k reception des 
donndes du serveur, appelle les 616ments du mod&Ie de visualisation correspondant 
presents dans le cache. On les associe et on opere la fusion pour la realisation par 
exemple d'une page a transmettre aux moyens de visualisation. 

[080] Si un element de construction n6cessaire n'est pas present initialement dans le 

cache, 1* operation d6crite pr6c6demment concernant sa transmission depuis la partie 
serveur au poste client est realisee auparavant. 

[081] Avantageusement, on exploite des donnees au format XML pour la creation du 
modele de visualisation et pour les donnees k afficher. Une traduction au format 
HTML peut etre op6ree apres la fusion par des moyens de transformation de fajon k 
obtenir un resultat sous forme de page HTML directement exploitable par une ap- 
plication de navigation conventionnelle. 

[082] On notera que Pobjet de la pr6sente invention assure une grande souplesse dans le 
d6veloppement des interfaces utilisateur graphique tout en limitant les volumes des 
donn£es transmises au travers des reseaux. Par ailleurs, le poste client ieste une 
structure legere et facilement installee et la partie serveur conserve un rdle primordial 
dans le traitement des donn6es et la gestion des elements de visualisation. 
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Revendications 

[001] Proc6de pour 1'interface graphique entre un utilisateur et un systeme in- 

formatique dans lequel on effectue les actions suivantes : entree d'une demande 
par l'utilisateur au niveau d'un poste client, transmission de la demande vers une 
partie serveur en vue du traitement de la demande et de la generation d'une 
reponse, reception de la reponse au niveau du poste client, affichage du resultat 
de la reponse pour l'utilisateur, caracterise par le fait que le poste client recoit 
une reponse comprenant des donnees d'instruction et des donnees a afficher ; au 
niveau du poste client, on execute les donnees d'instruction pour la construction 
d'un modele de visualisation a exploiter ; au niveau du poste client, on cree ledit 
modele de visualisation par association d' elements de construction disponibles 
localement, on fusionne les donnees a afficher avec le modele de visualisation en 
vue de T affichage du resultat de la fusion. 

[002] Procede selon la revendication 1, caracterise par le fait que les etements de 

construction comprennent une interface de description des objets du modele de 
visualisation, une couche de presentation et des regies logiques a appliquer 
localement au modele de visualisation. 

[003] Procede selon la revendication 1 on 2 dans lequel, caracterise par le fait que au 

niveau du poste client, on associe au modele de visualisation cree une ressource 
de langage parmi les ressources de langage disponibles localement ou tele- 
chargeables de la partie serveur. 

[004] Procede selon l'une quelconque des revendications 1 ou 3, caracterise par le fait 

que au niveau du poste client, on associe au modele de visualisation des filtres de 
personnalisation d'affichage pour modifier le rendu visuel du modele de vi- 
sualisation. 

[005] Procede selon l'une quelconque des revendications 1 a 4, caracterise par le fait 

que, les donnees d'instruction component I'indication du type et des elements de 
construction caract6ristiques de modele de visualisation k creer. 

[006] Procede selon l'une quelconque des revendications 1 a 5, caracterise par le fait 

qu'on met a jour les donnees disponibles localement au niveau du poste client 
par les etapes suivantes : on genere, au niveau du serveur, un message de 
stockage comprenant des donnees d'instruction de stockage et les donnees a 
stacker, on transmet le message de stockage au poste client, au niveau du poste 
client, on interprete les donnees d'instruction pour executor le stockage et on 
stocke les donnees & stacker dans une memoire locale. 

[007] Procede selon l'une quelconque des revendications 1 a 6, caracterise par le fait 

qu'on effectue l'affichage au niveau du poste client par une application de 
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navigation. 

[008] Proc&te selon 1 'une quelconque des revendications 1 & 7, caract6ris£ par le fait 

qu'on utilise des donates k afficher et des elements de construction des mod&les 
de visualisation au format XML, on traduit le resultat de la fusion au format 
HTML en vue de l'affichage. 

[009] Dispositif d' interfafage graphique entre un utilisateur et un systfcme in- 

formatique, comprenant : des moyens d' entree d'une demande par Tutilisateur au 
niveau d'un poste client, des moyens de communication entre le poste client et 
une partie serveur, des moyens de traitetnent dans la partie serveur pour la 
generation d'une r6ponse, des moyens d'affichage du r6sultat de la r6ponse au 
niveau du poste client, caracteris6 par le fait que, la r6ponse de la partie serveur 
comprend des donnges d' instruction et des donn€es k afficher ; il comporte, au 
niveau du poste client, un gestionnaire d'instnictions apte k interpreter les 
donnees destruction pour la construction d'un modele de visualisation k 
exploiter ; il comporte un moteur d* association au niveau du poste client apte a 
cr6er ledit modele de visualisation par association d'etements de construction ; il 
comporte des moyens de stockage des Elements de construction au niveau du 
poste client ; il comporte, au niveau du poste client, des moyens pour fusionner 
le modele de visualisation et les donnees k afficher, en vue de Taffichage du 
r€sultat de la fusion. 

[010] Dispositif selon la revendication 9, caract&isg par le fait que, les 616ments de 

construction comprennent une interface de description des objets du modele de 
visualisation, une couche de presentation et des regies logiques k appliquer 
localement au modele de visualisation. 

[01 1] Dispositif selon la revendication 10, caracteris6 par le fait qu'il comporte un 

moteur de rfegles apte k appliquer les regies logiques du module de visualisation. 

[012] Dispositif selon Tune quelconque des revendications 9 k 1 1, caracteris6 par le 

fait qu'il comporte une application de navigation pour Faffichage du rgsultat de 
la fusion au niveau du poste client. 
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[Fig. 001] 
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[Fig. 004] 
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